fix(docker): install the project after its sources are copied - #724
fix(docker): install the project after its sources are copied#724gkorland wants to merge 1 commit into
Conversation
pip install . ran with only pyproject.toml and uv.lock present, so
setuptools found no packages: the api package, the api.mcp templates
package-data and the console scripts never reached site-packages.
Because a console script resolves imports from its own bin directory
rather than the working directory, both entry points were broken in
the image:
cgraph BROKEN
cgraph-mcp BROKEN
which meant the documented CGRAPH_MODE=mcp path could not start at
all. Web mode only worked because uvicorn adds the working directory
to the import path.
Split the install: dependencies come from the exported uv.lock
requirements as before, keeping that layer cache-friendly, and the
project itself is installed with --no-deps after ./api and README.md
are copied.
Verified on the built image: cgraph and cgraph-mcp both run from
outside /app, the MCP server answers an initialize request, the
templates ship in site-packages, and web mode still resolves
STATIC_DIR to /app/app/dist and serves /api/list_repos with 200.
Addresses review feedback on #723.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Warning Review limit reachedNext included review available in 16 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR fixes the Docker image build so the CodeGraph Python package (including api.mcp templates package-data and the cgraph/cgraph-mcp console scripts) is actually installed into site-packages by installing the project only after its sources are copied into the image.
Changes:
- Switch dependency installation to
pip install -rfrom auv export-generated requirements file (pinned touv.lock), keeping the dependency layer cache-friendly and source-free. - Copy
README.mdand install the project itself withpip install --no-deps .afterCOPY ./api ./apiso packages, package-data, and entry points are present in the final image.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Summary
Follow-up to #723, which merged before this last review point could be addressed.
pip install .runs immediately afterCOPY pyproject.toml uv.lock ./, i.e. with no project sources present.[tool.setuptools.packages.find]therefore matches nothing, so theapipackage, theapi.mcptemplates package-data and the console scripts never reachsite-packages.Because a console script resolves imports from its own
bindirectory rather than the working directory, both entry points are dead in the shipped image:That makes the documented
CGRAPH_MODE=mcppath instart.sh(exec cgraph-mcp) unable to start at all. Web mode only works by accident, because uvicorn adds the working directory to the import path.Changes
uv.lockset directly (-r requirements.txt) instead of using it as constraints for a source install, keeping that layer cache-friendly and free of project sources.--no-depsafterCOPY ./api ./api, so the package, its package-data and both entry points land insite-packages.README.mdis copied alongside it, sincepyproject.tomldeclaresreadme = "README.md"for its metadata.Testing
Full build of the real Dockerfile, then inspected the resulting image:
Runtime smoke tests of both modes:
Application startup complete;GET /api/list_reposreturns200 {"status":"success","repositories":[]};GET /serves the SPA with200.CGRAPH_MODE=mcpanswers a JSON-RPCinitializehandshake, returningserverInfo.name = "code-graph". This previously could not start.No regression to web mode:
STATIC_DIRstill resolves against/app/api, because the working directory takes precedence oversite-packageson the import path.Memory / Performance Impact
N/A — build configuration only, no runtime code changed. Image size is unaffected: the same wheels are installed, just in a different order.
Related Issues
Follow-up to #723 (review feedback that arrived after merge).